I don't think either of these are the underlying problem, these objects are loaded by the QuarkusClassLoader, the statics should not prevent GC. I had a look at the reproducer and if you exclude RESTAssured the leaks go away.

The real issue seems to be some kind of reflection cache in groovy that is doing funky things with SoftReference. I will investigate further but I think there will likely be some horrible groovy hack required.

That's odd, I couldn't find any trace of Groovy in the memory snapshots, but I might have missed it

So I see it in yourkit as not being 'strongly reachable' (i.e. it is being held by either soft/weak references or objects pending finalization). The thing is though that non matter how much GC is run it still does no get cleaned up.

OK cool. I see it now as well.

I had checked Ignore soft/weak references

The thing is though that non matter how much GC is run it still does no get cleaned up.

Any idea what could be causing it?

If you add quarkus.class-loading.parent-first-artifacts=org.codehaus.groovy:groovy the leak goes away.

I think it is technically a JVM bug, where there are basically soft references going everywhere and it does not realize that the ClassLoaders are eligible for GC. Figuring out exactly what causes this will take some investigation though.

I don't think more investigation is warranted if we can just make Groovy parent first and be done with it

Closing